src/main/java/com/jobdri/jobdri_api/domain/mockapply/controller/MockApplyController.java (1)

85-93: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Swagger success examples are stale after adding sequence to create responses.

These endpoints now return MockApplyCreateResponse with sequence, but the documented 200 examples still omit it. Update the example JSON to include "sequence": <number> so API docs match runtime behavior.

Also applies to: 129-141

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/jobdri/jobdri_api/domain/mockapply/controller/MockApplyController.java`
around lines 85 - 93, Update the Swagger 200 response examples for the endpoints
that return MockApplyCreateResponse (notably the controller methods
createActualApply and the other create endpoint around lines 129-141) so the
example JSON includes the new "sequence" integer field; locate the
`@ApiResponse/`@Operation example JSON tied to MockApplyCreateResponse and add
"sequence": <number> (e.g., 1) to the example payload so the documented 200
response matches the runtime MockApplyCreateResponse structure returned by
mockApplyService.createActualApply and the corresponding create method.

src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java (1)

194-197: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Enforce positive sequence in service-level validation.

Line 195 currently accepts caller-provided sequence as-is. Since these are public service overloads, 0/negative values can bypass controller DTO validation and be stored.

🔧 Suggested fix

 private int resolveSequence(User user, JobPosting jobPosting, Integer requestedSequence) {
     if (requestedSequence != null) {
+        if (requestedSequence < 1) {
+            throw new GeneralException(
+                    GeneralErrorCode.INVALID_PARAMETER,
+                    "지원 순번은 1 이상이어야 합니다. sequence=" + requestedSequence
+            );
+        }
         return requestedSequence;
     }
     return Math.toIntExact(mockApplyRepository.countByUserIdAndJobPostingId(
             user.getId(),
             jobPosting.getId()
     )) + 1;
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java`
around lines 194 - 197, The resolveSequence method currently returns any
non-null requestedSequence; change it to only accept and return
requestedSequence when it's positive (requestedSequence != null &&
requestedSequence > 0), otherwise ignore it and compute the next valid sequence
number (e.g., query the existing max sequence for the JobPosting via the
repository/service and return max+1). Update resolveSequence(User user,
JobPosting jobPosting, Integer requestedSequence) to enforce this check and
fallback to the existing sequence-allocation logic so 0 or negative values are
never persisted.

src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java (1)

214-225: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Fix unsafe retry loop: don’t continue using the same transaction/session after saveAndFlush throws unique-constraint DataIntegrityViolationException.

When the insert fails on the unique constraint, Spring/JPA/Hibernate typically marks the current transaction and persistence context as rollback-only/invalid, so the later sequence++ retry attempts inside the same @Transactional flow are unreliable and may still end up failing/rolling back. Move each attempt into a fresh transaction boundary (e.g., extract the save into a @Transactional(propagation = REQUIRES_NEW) method called per retry), or use an atomic/locking-based sequence allocation approach to avoid the constraint violation in the first place. (src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java: 214-225)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java`
around lines 214 - 225, The retry loop in MockApplyService that calls
mockApplyRepository.saveAndFlush(MockApply.create(...)) inside the same
transaction is unsafe because a DataIntegrityViolationException leaves the
transaction/persistence context invalid; extract the save-and-flush into a new
transactional boundary (create a helper method, e.g.,
saveMockApplyInNewTx(MockApply) annotated with `@Transactional`(propagation =
REQUIRES_NEW)) and call that on each retry so each attempt uses a fresh
transaction, or alternatively implement an atomic sequence allocator/DB lock to
claim sequence numbers before persisting; update the loop to call the new method
instead of saveAndFlush directly and increment sequence between new-transaction
attempts.

src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java (1)

217-228: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Narrow DataIntegrityViolationException handling to the sequence-unique constraint only

MockApplyService.java lines 220-227 catch all DataIntegrityViolationException and treat them as sequence conflicts (either throwing INVALID_PARAMETER for explicit sequences or retrying/incrementing for auto-assigned ones). This can misreport unrelated integrity failures and mask real DB/data issues.

Handle only the uk_mock_apply_user_posting_sequence (i.e., detect the underlying unique-constraint violation via the most specific cause/constraint name/SQLState) and rethrow for other DataIntegrityViolationException causes.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/main/java/com/jobdri/jobdri_api/domain/mockapply/service/MockApplyService.java`
around lines 217 - 228, The catch for DataIntegrityViolationException in
MockApplyService around mockApplyPersistenceService.saveAndFlush is too broad;
change it to inspect the exception cause (e.g., ConstraintViolationException /
SQLException) and only treat it as a sequence-unique conflict when the
underlying constraint name or SQL state indicates the
uk_mock_apply_user_posting_sequence violation—on that specific match keep the
current behavior (throw INVALID_PARAMETER when requestedSequence is positive,
otherwise increment and retry); for any other DataIntegrityViolationException
causes rethrow the original exception so unrelated integrity errors are not
masked.